Subject: More information on Adaptive Session Pacing Indicator

From: "Tom Moore (8-444-9932)" <[email-masked]>
Date: Tue, 8 Mar 94 11:18:38 EST

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Here is some more information with regard to the discussion at the
AIW concerning ISR handling of the ASPI bit in RSP(BIND).  If a
back-level node that does not support adaptive pacing echoes the ASPI bit
(i.e., it incorrectly leaves the bit set to 1 in RSP(BIND)), the
incorrect setting can be detected if any of the pacing window sizes
in the RSP(BIND) are set to nonzero values.

If all the pacing window sizes are set to 0 because no pacing is to be
done in either direction, the incorrect setting of the ASPI could not be
detected (this situation should occur only when the BIND is
nonnegotiable; otherwise, the network node that forwarded the BIND will
not set the primary receive and secondary send window sizes to 0, and
the back-level node should not attempt to negotiate these values), and
the session would fail once the pacing protocol started.  The only
suggestion I have to prevent such an occurrence is for NOF in the
network node to specify that adaptive pacing not be done for sessions
to LUs in the back-level node; then, the network node would set the
ASPI in BIND to 0, and the back-level node would correctly echo the 0
value.

Gary Dudley                     [email-masked]   (919)254-4358
APPN Architecture
IBM Networking Hardware Division